Not applicable.
Not applicable.
The field of the invention is database management and more specifically methods and apparatus for automatically configuring a database as a function of the ways in which the data in the database is used.
While the present invention may be used in many different high information volume industries, in order to simplify this explanation, the invention will be described in the context of the building or enterprise automation (EA) industry. In addition, while the invention may be used with many different enterprises, the invention will be described in the context of an exemplary first enterprise owned by a first company and including seven separate campuses in different geographic regions where each campus includes a plurality of separate buildings and each building includes several thousand different environment condition sensors. Specifically, a first campus includes twenty separate buildings and each building includes two thousand separate sensors. In addition, it will be assumed that the first campus is in a location where the campus may receive its energy from either of three different utilities.
Moreover, separate sub-sections or parts of an enterprise will be referred to generally as units. For example, a sensor may be referred to as a unit. Similarly, a room (including many sensors), a floor of a building, a building, a campus, etc., may each be referred to as a unit. Other units may include a geographic area, a section of the enterprise related to a specific customer, a section of the enterprise serviced by a specific vendor, etc. Furthermore, while any of several different processors, work stations, etc. may perform the inventive functions, the invention will be described in the context of an exemplary system including a single database having a database processor and a single work station for accessing the database and manipulating data therein and also for receiving commands from a system administrator and providing reports and other data to the administrator. Here the station is used to interface with the processor and it will be assumed that the database processor performs essentially all data and database manipulation functions.
Furthermore, the term xe2x80x9cdata segmentxe2x80x9d will be used to refer to a subset of data values stored in a database where the sub-set may include anywhere from one to a theoretically infinite number of data values. In addition, while there are hundreds of functions that may be performed on data to generate data segment, unless indicated otherwise, the present invention will be described in the context of total and average power functions in order to simplify this explanation.
While there are many different costs associated with running any type of facility, recent energy shortages have made energy an ever increasingly important consideration in running many facilities. Fueled in part by increasing energy costs, facility administrators are now routinely charged with reducing energy, operating, and maintenance costs.
One way to reduce energy costs is to modify the ways in which energy is used in a facility and, where inefficiencies are identified, to modify the facility or energy use patterns to address the inefficiencies. For instance, in the case of the first campus described above, if off peak energy is delivered at a lower rate than on peak energy, first campus buildings may be cooled down in the morning during an off peak period prior to employees arriving to reduce energy costs. As another instance, cool air flow rate may be altered if a cooling system is more efficient than anticipated.
One other way to reduce energy costs is to identify errors in utility charges and receive credits. To this end, it is known that utilities monitor energy usage by collecting use data at periodic demand intervals. For instance, an exemplary demand interval may be every 15 minutes so that a utility collects a reading every 15 minutes. At the end of a billing cycle, the utility bases its energy charges on the demand interval readings. By measuring energy more regularly (e.g., every minute) and taking the average over the utility""s demand cycle, it has been found that often the demand interval readings are higher than actual average energy usage over the demand interval period. When confronted with such information utilities have routinely given credits to customers. In many cases the credits have amounted to as much as several percent (e.g., 10%) of the total energy bill during some billing cycles.
Yet one other way to reduce energy costs is to xe2x80x9cshopxe2x80x9d for energy by comparing energy rates from various utilities in an area. Thus, for example, in the case of the first campus described above, the campus administrator may select an energy provider from any of the three different utilities in the area.
In addition to reducing energy costs, facility administrators are also routinely charged with reducing maintenance costs and increasing up time of facility equipment. In order to reduce maintenance costs equipment can be diagnostically monitored to estimate when preventive maintenance should be performed. To this end, by trending operating characteristics of facility equipment (e.g., an HVAC system) and comparing the trending results with known failure patterns for similar equipment, impending problems with the equipment can be identified and addressed.
While several ways to reduce operating and maintenance costs have been described above, there are many other ways to reduce costs that a facility administrator can choose from and the examples above are not meant to be exhaustive.
One common characteristic of each of the cost saving processes described above is that, for each process to be most effective, each process requires collection of facility operating data. For instance, in the case of modifying energy use patterns, massive amounts of data have to be collected in order to identify inefficient energy patterns and other enterprise inefficiencies. Similarly, in order to identify utility mis-charges, energy readings have to be gathered every minute for a facility. In the case of the company described above that has many buildings on many campuses, the information that must be gathered is enormous. In the case of maintenance trending the amount data to be collected is massive.
Even the seemingly simple task of shopping around for the best deal on energy costs requires facility data collection and analysis. At first blush one would think that the best deal on energy costs could be determined by simply comparing utility rates. Unfortunately, often rates are different during different times of day and during different times of year. Complicating matters further, facility energy use is often very different at different times of day and different times of year. Thus, to determine the most cost effective utility form which to purchase power, historical energy use rates and times have to be collected and used as a proverbial xe2x80x9cglimpsexe2x80x9d into the future. For instance, knowing energy use patterns over a previous year period, an administrator can apply different utility rate schedules for the coming year to determine likely cost per utility and then select the least expensive option for a facility or enterprise.
Thus, the EA industry is not unlike other industries where, over the last several decades, computer workstations and related electronic devices have evolved to the point where they are now useful and, in many cases indispensable, tools needed for running businesses. Workstations and related devices have made it possible to collect massive amounts of information in a fraction of the time that would be required without the use of such tools.
Despite advancements in database management, related technological advances such as inexpensive sensors, standard network protocols (i.e., RMON, SNMP, etc.) and the ability to quickly and relatively inexpensively network data collecting devices together have, in some cases, rendered even relatively fast databases essentially unable to provide desired information crunching capabilities in an affordable product. For example, in the EA industry and, again considering the first campus described above, data may be collected every minute from each of thousands of environment condition sensors throughout the first campus and that data may be collected over the course of several years. For instance, a building chiller mounted on the top of a building may have four different sensors including an inlet temperature sensor, an inlet pressure sensor, a discharge temperature sensor and a discharge pressure sensor. As another instance, temperature, pressure, humidity and air flow sensors may be placed in each room within each building on the first campus for measuring respective parameters.
In this case, it may be advantageous to examine the raw data collected by the separate sensors. More likely, however, a system administrator may want to examine some aggregate of the collected data such as the average temperature in a room over an interval (e.g., a 15 minute interval) or the average temperature over 15 minute intervals over the course of a 12 month period. Another likely interesting data aggregate may include power consumption in a particular building on a daily basis over the course of a sixty month period so that any power spikes can be identified and their causes determined. Yet another likely interesting data aggregate may be to examine the power consumption for two similar buildings and compare consumption between the two buildings. Many other requests are contemplated.
While there are many interesting data aggregates or segments, even with relatively fast computers or work stations, combining raw data together to generate the interesting data segments is time consuming. For instance, combining raw data that has minute intervals over the course of several years to generate total energy consumption for the exemplary company described above would likely take more time (e.g., perhaps on the order of tens of minutes) than a system administrator is willing to wait. This is particularly true in comparative situations where many such requests may be needed to generate the comparative information as, for instance, where such energy consumption for each year over a ten year period is to be compared.
Where only a small number of data segments are required routinely, such processing periods may be tolerable. Unfortunately, in most cases, system administrators would prefer to access data segments that slice and dice data in many different ways and in these cases, because of the multiplicity of ways in which the data must be viewed in a finite data analysis period, long waiting periods cannot be tolerated.
One solution to this problem has been to specify specific report types to be supported by a system and then effectively program database functions (e.g., roll ups, etc.) that generate data segments that are needed to provide the supported reports when the information required to generate the segments becomes available. Then, when an administrator requests a particular report, the database processor simply accesses the data segments needed to instantiate the report and generates the report. In effect each pre-calculated data segment is a cache of useful information that will be used at subsequent times to generate reports of one or more different types.
While pre-calculated data segments and caching have streamlined the report generating process, such data manipulation techniques have several short comings. First, configuring database functions is extremely time consuming and has to be performed by an experienced database programmer. Prior to a system administrator using a database, a database programmer has to specify virtually every aspect of each system supported function. General function aspects include the raw data to be combined to form the data segment (i.e., the units or sensors from which to collect data), the actual combining function steps (e.g., total energy consumption, average temperature, etc.), the units of measure for the function result and the interval over which the function should be applied. In addition, the programmer has to specify where within the database the data segment will be stored so that subsequent access can be expedited. Typically this step of specifying database location required modifying the structure of the database by specifying a new database table specifically earmarked to receive the new data segments.
Not surprisingly, the time required to specify supported functions is directly related to the number of functions to be supported. In the case of a large enterprise there are virtually millions of ways in which raw data can be combined and parsed. For instance, data can be parsed on a sensor by sensor (i.e., where the unit is a sensor) basis over various interval/function combinations, on a room by room basis over various interval/function combinations, on a building by building basis over various interval/function combinations, on a campus by campus basis over various interval/function combinations, on an enterprise wide basis over various interval/function combinations, by selecting specific buildings having similar characteristics from each of the campuses over various interval/function combinations, by selecting specific sensors having similar characteristics from all campuses, etc. In these cases a different function or segment for each unit-intervalfunction combination would have to be specified.
Second, the effectiveness of pre-canned data segments in speeding up data processing is user dependent. In fact, in many cases, pre-canned data segment roll ups may not appreciably speed up data manipulation at all. To this end, while a programmer can identify certain generally useful data segments, there is no way for the programmer to anticipate which data segments will be most useful to a particular administrator and therefore, in many case, certain data segments may only rarely be employed. For instance, where a pre-canned data segments includes total monthly energy consumption for each building on each campus but an administrator wants consumption on a weekly basis for each building, either the system will not allow the administrator to generate weekly data segments or the database processor will have to be programmed to revert back to combining the raw data when the request is entered, a task that could take several minutes to complete.
Third, repetitive requests for data segments that are not supported by pre-canned segments result in repetitive processing and waiting periods that are burdensome to system administrators. To this end, assuming that a data segment is requested that is not pre-canned, upon receiving the request, the database processor performs a first process including accessing the raw data, combining the data and providing the requested segment. This first process may take several minutes. Some time thereafter (e.g., the next day), the administrator may again want to access data similar to that accessed pursuant to the first process but updated to include data from the intervening time period. In this case, when a second process request is again received, the database processor responds to the second request by accessing the raw data, combining the data and providing the requested segment. The time required to facilitate this second process would be slightly longer than the time required to perform the first process, the additional time needed to accommodate the data corresponding to the intervening time. Thus, in many cases, another several minute wait would be necessary to generate the requested data segment. Clearly this repetitive computing requirement exacerbates the data review process.
In a case where data is manipulated in a similar fashion repetitively and routinely, one solution is to have the programmer reconfigure the database to support additional useful data segments. While possible, manual database reconfiguration is cumbersome and would be very difficult to administer for several reasons. First, administrators likely would not be familiar with the ways in which data segments could be configured. To this end many administrators are not technically savvy and therefore would never inquire as to segment pre-canning capabilities.
Second, most companies do not have programmers on staff to reconfigure databases to accommodate administrative requirements on the fly. Instead, separate database consultants are often used to customize segments and other reporting features which adds costs to the system as a whole.
Third, given the costs and troubles associated with reconfiguring a database to support additional segmentation, it may not be clear to an administrator when reconfiguration is warranted. For instance, what if similar data segments are required only every six months and each time the particular segment is generated only 10 minutes are required. Would these circumstances warrant modification?
While the problems described above exist on a facility by facility basis, the problems are exacerbated where many facilities are managed by a single administrator. For instance, recently, a remote facility monitoring industry has evolved wherein industry members provide remote monitoring services to clients. In these cases, a provider may provide services to several hundreds or even thousands of facilities in many geographic locations. In this case data from literally millions of sensors would have to be collected, archived and manipulated.
Thus, there clearly is a need for a database and a method for manipulating the database where database query results can be quickly determined without requiring massive amounts of manual programming.
It has been recognized that a database can be configured that effectively xe2x80x9clearnsxe2x80x9d during use and generates and stores data segments that are routinely used thereby reducing the time required to generate subsequently requested reports that include the data segments. Thus, according to one embodiment of the invention, when a report is requested via a work station, a data segment is needed to instantiate the report and the data segment is not already stored in a database, a database processor generates the requested data segment, stores the data segment for subsequent use and then provides the data segment in a report to the requesting user. Thereafter, when a subsequent report request requires a data segment similar to the newly stored data segment, if possible, the database processor employs the existing data segment and adds additional information to the data segment if necessary, to provide the similar segment.
In addition, in at least some inventive embodiments, when a request causes the database processor to combine data segments to create a new data segment, in addition to generating and storing the new data segment, the processor also causes intervening data segments to be generated and stored for subsequent use. For instance, assume that power consumption data is generated and stored as raw data every minute for every building owned by a particular company. In addition, assume that an administrator requests a report comprising data segments for a first period including the last sixty months (i.e., last five years) for each building showing monthly total energy consumption for each building. In this case, the database processor may begin by rolling the minute data into fifteen minute intervals and storing the fifteen minute interval data segments as intermediate data segments. Next, the processor may roll up the fifteen minute data segments to hourly data segments and then the hourly to daily, and the daily to monthly, the processor storing each of the intermediate roll-up data segments for subsequent use.
Thereafter, the sub-period data that has been rolled up corresponding to the 15 minute, hour and day intervals can be used subsequently to instantiate other requested reports to speed the process of data delivery to the administrator. Thus, if, after viewing the monthly power consumption information, the administrator wishes to view daily power consumption information corresponding to at least a portion of the first period (i.e., a sub-period of the last sixty months), the processor can quickly provide the desired information as the daily power consumption information has already been determined and stored in the database.
As another example, assume that an administrator requests average daily power consumption data for the entire first campus described above for each month during the course of a ten year period. In this case raw power consumption data over the course of each month is rolled up for the entire campus and the daily averages for the requested months are determined by dividing the rolled up values by the numbers of days in corresponding months. In addition, during the roll up process, the total energy consumption for each building for each of several sub-intervals may be rolled up as separate data segments and stored. For instance, the power for a first building may be rolled up by the minute, the hour, the day and the month, each of these roll ups stored as a separate data segment. In addition, the total power for each floor in each building for each of the sub-intervals may also be rolled up and stored. Moreover, the power for each piece of equipment for each floor in each building for each of the several intervals may be rolled into a data segment and stored. Furthermore, while the average daily power is desired, to obtain the average, the total power for the entire month must first be calculated and then the total divided by the number of days in the month. Thus, the total power per each interval per each separate unit (e.g., sensor, floor, building, campus, etc.) may also be stored as a separate data segment for subsequent use.
It should be appreciated that, while the initial process of generating rolled up data segments or data segments corresponding to more complex functions according to this inventive method has performance characteristics that are similar to the those obtainable via previous database management solutions, subsequent data requests requiring a subset of data corresponding to previously determined roll-ups and solved functions are expedited.
It should also be appreciated that the time required to acquire and store intermediate roll ups, even when not required for a particular request, is minimal and, therefore, the added benefits of acquiring and storing the intermediate roll ups are reaped without much computing overhead. To this end, the intermediate data segments are determined, as the term xe2x80x9cintermediatexe2x80x9d implies, as intermediate results required to generate requested data and therefore the only additional computing costs required to acquire and store the intermediate data segments are simply periodic data storage routines.
In addition, the present invention provides a system that requires no pre-canned roll ups. Instead, the system learns which roll ups may be useful in the future from previous use.
Moreover, the effectiveness of generated roll ups xe2x80x9con the flyxe2x80x9d over pre-canned roll ups is increased as the roll ups that are generated are a function of administrative activity. Thus only roll ups requested by an administrator or intermediate roll ups related thereto are generated and stored. Because administrators typically become comfortable over time viewing certain types of reports with known characteristics, the likelihood of a particular administrator requesting a report that requires a previously requested roll up is greater than the likelihood of requesting a report that requires some new roll up. Similarly, even where an administrator""s request requires a roll up not previously required to instantiate a report, the likelihood of the new roll up having similar characteristics to a previously required roll up is higher than the likelihood of the new roll up having unique characteristics and therefore there is a good chance that the new roll up will correspond to a previously generated and stored intermediate roll up. For instance, assume an administrator requests and views monthly average energy consumption over several years for an entire enterprise and notices a spike in a particular month. A next logical report request may be to view daily average energy consumption for the particular month, for the entire enterprise. As described above, according to one aspect of the invention, an intermediate roll up generated and stored while the average monthly energy consumption roll up was being generated would be average daily energy consumption for the enterprise and therefore the data segment needed to instantiate the next request would already be present and could be used to rapidly (e.g., effectively in real time) generate the report.
The invention also includes a database concept referred to as a xe2x80x9cpoint slicexe2x80x9d that helps organize a complex dynamic database and facilitates dynamic data storage. To this end, it has been recognized that virtually any data sub-set in a database can be completely characterized by a relatively small number of data attributes. For example, in the case of enterprise automation systems (i.e., building automation), any data segment (i.e., data subset) can be completely characterized by unit, function, interval and time period attributes where the unit attribute corresponds to a particular sub-grouping of hardware associated with (e.g., generating raw data needed to generate the data subset) the segment, the function attribute corresponds to a function (e.g., a roll-up, an average, a more complex calculation, etc.) performed on some data to generate the data segment, the time period attribute corresponds to the period over which the data in the segment is collected and the interval attribute corresponds to the durations of sub-periods during the time period over which the function is applied to generate data values in the data segment. For instance, a first point slice may correspond to a single power consumption monitor (i.e., the unit is the monitor) for which raw power consumption data is to be rolled up (i.e., the function is to add up consumption readings) to generate monthly total consumption values (i.e., the interval is monthly) for the 60 month period beginning Jan. 1, 1996 and ending Dec. 31, 2000 (i.e., the period is Jan. 1, 1996-Dec. 31, 2000). As another instance, a second point slice may correspond to total energy consumption (i.e., function is total energy consumption) throughout the exemplary first enterprise described above (i.e., the unit is the entire enterprise) having a time period of three years and over the course of monthly intervals. One other instance may include a third point slice corresponding to a single power consumption monitor (i.e., the unit is the monitor) for which a single power consumption reading is to be stored (i.e., the function is simply xe2x80x9cnullxe2x80x9d), where the interval is a minute and the time period is continuous meaning that raw data values are to be stored.
Thus, consistent with the point slice concept, every data segment (i.e., data subset) is stored as a unique point slice characterized by the minimum number of attributes required to uniquely identify the segment. In addition to providing data that is easy to reference by storing all segments as point slices, the present invention enables all segments to be stored in a single simple database capable of supporting theoretically an infinite number of different roll ups and data segments without requiring modifications to the database structure. Thus, for instance, where a request requires a new roll up that was not previously generated and stored, after the roll up is generated, the roll up is stored as a point slice according to unit, function, time period and interval in a single data base structure (e.g., a table).
In summary, in at least one embodiment, a point slice includes a data segment correlated with segment attributes that uniquely distinguish the particular segment from all other segments.
The invention also includes a method to be used with a database and an interface, the interface for specifying reports to be generated, the database capable of including a hierarchy of point slices where each point slice includes a data segment and at least a subset of the data segments can be combined to instantiate each specified report, the method for expediting the report generating process and comprising the steps of (a) receiving a report request; (b) identifying at least one required point slice required to instantiate the report; (c) searching the database for the at least one required point slice; (d) where the at least one required point slice does not exist, identifying an intermediate subset that includes intermediate point slices required to generate the at least one required point slice; (e) determining if the intermediate subset point slices exist; (f) for each non-existent intermediate subset point slice, using existing point slices to generate the non-existent intermediate point slice; (g) combining the intermediate subset point slices to generate the at least one required point slice; and (h) instantiating the report using the at least one required point slice.
In some embodiments the method further includes the step of, after generating the non-existent required point slice, storing the generated required point slice for use when subsequent reports are requested. In other embodiments the method further includes the step of, after generating the non-existent intermediate subset point slices, storing the generated intermediate subset point slices for use when subsequent reports are requested.
In one aspect the step of using the existing segments to generate the non-existing intermediate subset point slices includes, for each non-existing intermediate subset point slice, repeating steps (c) through (g) with the intermediate point slice as the required point slice to determine the intermediate point slice. In another aspect at least a subset of the generated intermediate subset point slices are stored for subsequent use. In some cases every generated intermediate subset point slice is stored for subsequent use.
The step of identifying at least one required point slice needed to instantiate the report may include receiving a report request and parsing the report request to identify the at least one point slice. The method may be for use in an enterprise automation system including at least one unit, the unit including at least one data source element and wherein each point slice includes data corresponding to a specific function, a specific period and specific intervals within the period for a specific unit and wherein the step of receiving includes receiving an indication of a particular unit, a time period for which to report data corresponding to the unit, an interval and a function to be performed on data corresponding to the unit, the step of identifying including identifying a point slice corresponding to the specified unit, function, time period and interval.
The step of identifying may further include identifying relevant data types required to perform the specified function, identifying relevant unit source elements that provide the relevant data types and identifying relevant point slices corresponding to the relevant units, interval, time period and function. Here the step of combining the point slices may include combining data segments corresponding to the relevant units according to the specified function.
The invention further includes a method to be used with a database and an interface, the interface for specifying reports to be generated, the database capable of storing a hierarchy of points slices where each point slice corresponds to a data segment and where a subset of the data segments can be combined to instantiate each specified report, the method for automatically modifying a database structure as a function of specified reports to speed subsequent report generation and comprising the steps of: (a) receiving a report request; (b) identifying at least one required point slice needed to instantiate the report; (c) searching the database for the at least one required point slice; (d) where the at least one required point slice does not exist, identifying an intermediate subset that includes intermediate point slices required to generate the at least one required point slice; (e) determining if the intermediate subset point slices exist; (f) for each non-existent intermediate subset point slice, using existing point slices to generate the non-existent intermediate subset point slice; (g) combining the intermediate subset point slices to generate the at least one required point slice; and (h) storing the at least one required point slice.
The step of using the existing point slices to generate the nonexisting intermediate subset point slices may include, for each non-existing intermediate subset point slice, repeating steps (c) through (g) with the intermediate point slice as the required point slice to determine the intermediate point slice. The method may further include storing every generated point slice for subsequent use.
The invention also includes a method for use with a processor, an interface and a plurality of source elements, the interface for specifying report requests, each report request including request information that can be used to identify point slices and corresponding data values where a sub-set of the data values are needed to instantiate each report, the source elements periodically generating raw data values and providing the raw data values to the processor, the processor for receiving data values and report requests, combining the data values to generate combined data values as a function of the report requests and storing the data values in corresponding point slices for subsequent use in generating subsequent reports pursuant to subsequent requests and generating reports using the data values, the database comprising: an existing point slice identifier identifying existing point slices; and a point slice specifier indicating how to combine existing data values to generate non-existing data values and corresponding point slices.
Each combined data value may include data from more than one source element and each point slice is characterized by unit, period, interval and function attributes, the unit attribute indicating the source elements that produce signals used to generate the data values, the period attribute indicating a period to which the slice corresponds, the interval attribute indicating a duration between data values in the point slice and the function attribute indicating a function applied to at least one of source element signals and data values to generate the data values in the point slice, the existing point slice identifier indicating each of the function, unit, interval and period corresponding to each existing point slice.
Each request may include a unit attribute and wherein the specifier, for at least some of the units, indicates sub-units that comprise the units. Each request may include a function attribute and wherein the specifier, for at least some of the functions, indicates sub-functions that comprise the functions. Each request may include a period attribute and wherein the specifier, for at least some of the periods, indicates sub-periods that comprise the periods. Each request may include an interval attribute and wherein the specifier, for at least some of the intervals, indicates sub-intervals that comprise the intervals.
The method may be for use in managing a building automation system wherein the unit attribute is selected from one of a customer unit, a supplier unit, a geographic region unit, a person unit, a campus unit, a building unit, a floor unit and an equipment unit.
The method may be for use in managing a building automation system and the interval attribute may be selected from one of a yearly interval, a quarterly interval, a monthly interval, a daily interval, an hourly interval and a minute by minute interval.
For at least some point slices, the specifier may indicate other point slices to be manipulated according to a function to generate a requested point slice. Each request also may include a unit attribute and the point slice specifier correlates the unit attributes with specific sub-sets of source elements.
Moreover, the invention includes a method to be used with a database where a plurality of data segments are stored in the database, at least some of the data segments correlated with point slices in the database, the method for expediting the process of accessing combinations of the data segments upon request and comprising the steps of: receiving a report request; identifying at least one required point slice required to instantiate the requested report; if the at least one required point slice does not exist, identifying intermediate point slices that can be combined to provide the required point slice; combining the intermediate point slices to generate the required point slice; during the step of combining the intermediate point slices, determining if the combining process generates intermediate point slices that may be useful during subsequent requests; and where there are useful intermediate point slices, storing the useful intermediate point slices for subsequent use.
Here the method may further include the step of storing the generated required point slice.
The report request may include a function attribute specifying a function to be performed to generate the data segment corresponding to a point slice needed to instantiate the requested report and the function may include at least one sub-function, the combining step including solving the sub-function and the step of determining including identifying the data segment and intermediate point slice corresponding to the solution of the sub-function.
The report request may include a unit attribute specifying source elements from which data segments are to be combined to generate the point slice needed to instantiate the requested report and wherein the unit includes at least two sub-units, the combining step including combining the data elements for each of the two sub-units separately and the step of determining including identifying the data segments and intermediate point slices corresponding to each of the two sub-units.
The report request may include an interval attribute specifying an interval over which data segments are to be combined to generate the point slice needed to instantiate the requested report and wherein the interval includes at least first and second sub-intervals, the combining step including combining the data segments foe each of the first and second sub-intervals separately and the step of determining including identifying the data segments and intermediate point slices corresponding to each of the first and second sub-intervals.
Furthermore, the invention includes a method to be used with a database where a plurality of data segments are stored in the database, at least some of the data segments correlated with point slices in the database, the method for expediting the process of accessing combinations of the data segments upon request and comprising the steps of: receiving a report request including a first time period over which data having a first set of attributes is needed to instantiate the requested report; determining if there is an existing first point slice having the first set of attributes over a second time period where the first time period includes at least a time segment in addition to the second time period; where the first point slice exists, generating a second point slice having the first set of attributes and including data corresponding to a new period including the first and second periods and any intervening period.
Here the method may further include the step of storing the second point slice. The method may further include the step of deleting the first point slice and the step of using the second point slice data values to instantiate the requested report. Moreover, the method may include the step of presenting the instantiated report to a requesting system user.
The invention further includes a database construct for storing data values corresponding to specific source elements, the construct comprising: a plurality of point slices wherein each point slice includes at least one data value, each slice correlated with unit, function, interval and time period attributes, the unit attribute indicating the source elements that produce raw data used to generate corresponding point slice data values, the period attribute indicating a period to which the slice corresponds, the interval attribute indicating a duration between data values in the point slice and the function attribute indicating a function applied to data values to generate the point slice data values.
These and other objects, advantages and aspects of the invention will become apparent from the following description. In the description, reference is made to the accompanying drawings which form a part hereof, and in which there is shown a preferred embodiment of the invention. Such embodiment does not necessarily represent the full scope of the invention and reference is made therefore, to the claims herein for interpreting the scope of the invention.